home *** CD-ROM | disk | FTP | other *** search
/ Network Support Library / RoseWare - Network Support Library.iso / pressgen / token.err < prev    next >
Text File  |  1992-09-14  |  7KB  |  175 lines
  1. This incident report is provided as supporting documentation for a message 
  2. left on NetWire on 9/9/92.  The message describes some problems with the new
  3. Token Ring drivers for 3.11, and omissions in the update documentation shipped 
  4. with the drivers.
  5.  
  6. The following document referrs to several servers by name.  NN_server, and 
  7. DEVELOPMENT_server and NW 3.11 servers.  IBM PS/2 model 95s w/ 16MB RAM.  
  8. These servers reside on a Token Ring network along with two other NW 2.2 
  9. servers.
  10.  
  11. The Token Ring is monitored by Proteon's network monitoring system.  The 
  12. Proteon system reports media aquisition (MAC) layer errors.
  13.  
  14.  
  15. Please pardon me if the document rambles a bit, but these reports are used for 
  16. future problem determination and evaluation.  Our support group feels that 
  17. every idea committed to paper helps.
  18.  
  19.  
  20. Larry Rubanka,
  21. 73465.643
  22.  
  23.  
  24.  
  25. INCIDENT REPORT:
  26.  
  27. NN_server, running Netware 3.11 using TOKEN.LAN v3.13 uninterrupted up time, 
  28. 100+ days.
  29.  
  30. Installing the Netware for SAA v1.2 placed the new TOKEN.LAN v3.16 on 
  31. NN_server.  This new LAN driver was loaded and running for several days.  
  32. SAA NLM was not running, or loaded.
  33.  
  34. Two similar, probably identical, events occurred within two weeks following 
  35. the SAA installation.  No similar events had occurred before the SAA 
  36. installation.
  37.  
  38.  
  39. SYMPTOMS OBSERVED:
  40.  
  41. 1) A number of Receive Congestion (RC) errors reported by the Proteon network 
  42. monitor.  These RC errors were on the ring used by four different servers and 
  43. over 100 node.
  44.  
  45. 2) Token Ring was passing data, and workstations could log into and use other 
  46. servers.
  47.  
  48. 3) No errors were reported on any servers, including NN_server.
  49.  
  50. 4) SLIST did not show NN_server yet still showed other servers.
  51.  
  52. 5) Performance, at workstations not using NN_server, was not noticeable 
  53. affected.
  54.  
  55. 6) SNA gateway was in use and functioning.
  56.  
  57. 7) Workstations attached to and accessing NN_server encountered errors.
  58.  
  59. 8) Packet Receive Buffers on NN_server climbed continuously, and server 
  60. utilization showed 25%.  This is high compared to our normal 5-10% level.
  61.  
  62. 9) Another 3.11-based server, DEVELOPMENT_server, was running TOKEN.LAN v3.13 
  63. and was functioning properly.  Packet Receive Buffers and percent utilization
  64. of DEVELOPMENT_server were normal.
  65.  
  66.  
  67. SOLUTIONS TRIED:
  68.  
  69. 1) Excluded (disallowed access to the ring) any workstations reporting MAC 
  70. layer Token Ring errors.  No effect.
  71.  
  72. 2) Restarted several workstations that were reporting MAC layer errors.  No 
  73. effect.
  74.  
  75. 3) Eliminated all "Receive Congestion" errors from network by restarting any 
  76. workstations reporting errors.
  77.  
  78. 4) Shut down NN_server, and restarted it.  The problems recurred within ten 
  79. minutes, after other RC errors.
  80.  
  81. 5a) Unloaded TOKEN.LAN v3.16.  Stopped Packet Receive Buffer growth.  Percent 
  82. utilization dropped to zero.
  83.  
  84. 5b) Loaded older TOKEN.LAN v3.13.  Resumed server operation without errors.  
  85. Logged in and out, used SLIST and SNA services.  Everything was functioning 
  86. properly at this point.
  87.  
  88. 5c) Shut down and restarted NN_server to reallocate RAM appropriately (can not 
  89. deallocated Packet Receive Buffers).  No problems since.
  90.  
  91.  
  92. CONCLUSIONS:
  93.  
  94. 1) The problem seems local to the NN_server.  DEVELOPMENT_server, similarly 
  95. configured, showed no problems, nor did other 2.2-based servers.
  96.  
  97. 2) A significant difference between DEVELOPMENT_server, and NN_server is the 
  98. TOKEN.LAN version.  These servers also use different disk drivers.
  99.  
  100. 3) Receive Congestion errors are rare on our network.  In both cases, the
  101. incident was preceeded by Receive Congestion errors.  Cause or effect?  Could 
  102. the Receive Congestion errors have "triggered" the problem with v3.16 
  103. TOKEN.LAN, or were they merely a symptom of the problem?  DEVELOPMENT_server, 
  104. running TOKEN.LAN v3.13, did not have any problems dealing with these errors.
  105.  
  106. 4) In both incidents, the RC errors occurred when a PC experienced an error 
  107. under QEMM 386.  I speculate that QEMM has paused the CPU and that the receive 
  108. buffer on the TR card is not being serviced.  The card continues to function, 
  109. however, and reports the RC errors.
  110.  
  111. 5) Due to time and availability constraints, unloading and reloading the 
  112. TOKEN.LAN v3.16 was not tried.  However, TOKEN.LAN was stopped and 
  113. restarted via the NN_server shut down and restart.  Restarting the server, and 
  114. hence the driver, did not eliminate the problems.
  115.  
  116. 6) The TOKEN.LAN v3.16 seems to be problem.
  117.  
  118.  
  119. NOTES:
  120. The SAA installation introduced a new version of NMAGENT.NLM.  This is not 
  121. used by other servers.
  122.  
  123. SAA installation was not completed due to errors encountered with 
  124. configuration values.
  125.  
  126. The documentation for TOKENDMA.LAN describes a condition where the driver 
  127. pauses execution until beaconing stops.  This pause accounts for the queuing
  128. of ECBs.  I believe that the driver's behavior differs significantly from that 
  129. which is described in this documentation.
  130.  
  131. After adopting the TOKEN.LAN version 3.16, shipped with SAA, I recognized a 
  132. problem similar to that described in the update docs.
  133.  
  134. I am making some assumptions to help me work around the omissions in the 
  135. update documents.
  136.  
  137. I assume the behavior of v3.16 TOKEN is similar to v3.16 TOKENDMA with regards 
  138. to it's reaction to "Beaconing" errors.  I am also assuming that the queueing 
  139. of ECBs in the send queue would drive up the number of Packet Receive Buffers 
  140. alocated and/or the Permanent Pool memory.
  141.  
  142. Given these assumptions, I have observed the following behavior of the 
  143. TOKEN.LAN v3.16 driver.
  144.  
  145. The driver appears to pause when a "RECEIVE CONGESTION ERROR" (RC error) 
  146. occurrs.  The driver does not appear to resume when the RC error is cleared.
  147. Several minutes (20 or more) after the node(s) reporting RC errors are 
  148. removed, the server still is unavailable.
  149.  
  150. In the presence of RC errors, the 3.16 TOKEN.LAN driver appears to pause.  The 
  151. Permanent memory pool continues to grow.  Packet Receive Buffers (PRBs) grow.  
  152. I have not waited for the PRBs to grow up to Max PRB.  
  153.  
  154. While the PRBs and Permanent memory grow, the server continues operating.  
  155. Only Token Ring activity has paused.  MONITOR continues to function as well as 
  156. do other NLMs.
  157.  
  158. If a connection is specified for clearing via MONITOR while the driver is 
  159. paused, monitor pauses.  With monitor paused, the server is STILL functioning.  
  160. If MONITOR is unloaded from the console, the console pauses.  I would expect 
  161. this behavior if the driver were paused.  I presume that if the driver 
  162. resumed, the clear connection would proceed, and the unload would continue.
  163.  
  164. Clearing the RC errors does not cause the driver to resume, at least not 
  165. quickly.  I waited approximately twenty minutes after eliminating all MAC 
  166. layer errors, but the driver remained paused.
  167.  
  168. The RC error is reported when a Token Ring interface's receive buffer is not 
  169. being serviced, and overflows.  This is a node error, not a ring error.  Token 
  170. Ring traffic continues in the presence of RC errors.  To the best of my 
  171. knowlege, this is not "Beaconing."
  172.  
  173. While the RC errors persist, the Token Ring continues to pass traffic.  Other 
  174. 3.11 servers running v3.13 TOKEN.LAN continue normaly, as do 2.2 servers.
  175.